thoughts on improving the experience of configuring a linux machine

I'm interested in improving the state of Linux Configuration. I think it is possible to create a sustainable system for administring a linux computer. By sustainable I mean that the linux developement community can easily maintain and update this system. The system will need to be updated when legacy programs change their configuration files.

Configuration Notes 05-14-06- notes from the plane
Configuration Schema Article - draft of article for developer works
Configuration Schema Article v2 - new take on article for developer works
SSH Client Config Schema - an example of a config schema and its usefulness
Improving Linux Configuration Plan
Improving Linux Configuration Plan2
Config Editor
Whitespace Model

Here are some links related to this subject:

• http://www-106.ibm.com/developerworks/linux/library/l-config.html - A nice list of config files.
• http://forums.gentoo.org/viewtopic-t-23640.html - this is the gentoo faq forum. They had at least two interesting threads about improving the linux experience. One mentioned making lists of config files. If there was a framework for documenting these config files, and if an output of this framework would be useful to this group, then they might help maintain it.
• http://freshmeat.net/articles/view/565/
• http://www.desktop-linux.net/linuxconfig.htm
• http://config4gnu.sourceforge.net/ - this looked very promising but it has been dormant
  for months.
• http://www.libconf.net/ - perl library for handling configuration files
• http://imc.sourceforge.net/home.html - a framework for building web management consoles. I think it uses or will use libconf
• http://conf2xml.sourceforge.net/ - a library to make xml from config files.

I believe such a system could unite the efforts of the gui configuration projects:
webmin, gnome system tools, linuxconf, kdeadmin, suse YaST.

From what I understand the config4gnu project has the most advanced (and complicated) way of handing linux config files. There are parsers that can handle different config file types. These parsers turn the file into a generic XML format. Then a Schema is written for each config file. The schemas are in a standard format because they validate the generic XML format. From what I understand handling a new config file requries:

• checking if it uses a format for which there is a parser aready written
  • maybe customize this parser (I think this should be unnecassary)
• write a parser if one doesn't exist
• write a schema to validate the resulting xml format.

I assume this schema is used to create a generic UI for modifying the config file.

This is identical to what I wanted to do.

However this project seems dormant or delayed. But the SBLIM and CIMOM groups see to be picking up steam. However, I don't know if they have an advanced technique for dealing with linux config files with schemas etc. It seems CIM has a form of schema but it is at the high level description of the computer. Perhaps this mechanism can be used at the low level too:

• the text config files are turned into cim format using modified versions of the config4gnu parsers.
• then the schema files are written as CIM models for this cim format data.
• then there probably needs to be a translation or combination step where this low level cim data is turned into offical CIM schema data.

For example the network config file is first turned into cim format data using a one-to-one parser. Then this one-to-one cim format data is turned into offical CIM Network data.

This paper indicates a slightly different approach at the end of the paper: http://www-124.ibm.com/sblim/doc/cimappcfg.pdf
It talks of an AST which is an in-memory representation of the text config file. Then this is mapped to the CIM objects, which I believe have their own schemas in the form of a MOF. I'd imagine there would need to be a second schema in this approach. This schema would need to restrict what could be done to the AST and still keep it valid. This would be need for services that don't implement the full functionality of the high level CIM objects. For example a web server that doesn't everything a "generic" web server should do. Perhaps the CIM/WBEM spec has a way of handling this already.

One interesting point from this paper is the mention of using syntaxtic parsers to handle the text config file. I've never used one of these parsers, but they might be easier to configure than the perl parsers used by the Config4GNU project.

Looking at the Config4GNU-wbem pages it seems they are doing the following:

• using existing config4GNU parsers to convert text config files into semi-generic xml.
• using schemas to validate and control what goes into these semi-generic xml files.
• then using a set of wbem providers to translate between the semi-generic xml into standard CIM and back again.

One disadvantage of this is approach is the similarity between the semi-generic xml format and CIM. If it is possible to represent the semi-generic format in CIM. Then all the CIM browsers could browse the lowlevel config files as well as the more abstracted standard CIM schema.

Another thought about the Config4GNU work is to use it to improve documentation of these text config files. If text config files can be grouped into types, and each file can be described by its type and specific schema. Then the schema could be annotated with documentation. And this schema could be used to generate well formated config file documentation (like web pages or doc book).

Apache already has this type of documentation
http://httpd.apache.org/docs-project/docsformat.html
The documentation is stored in xml that could be used for the schema of the apache config file.

I bet other projects have this type of well formed configuration documentation too. This means the schemas are already taken care of for some projects. +1 for sustainability. For projects that don't have well formed documentation, showing gui config applications that use this documentation might motivate them to maintain well formed docuementation.

Other config notes:
If the system is going to change the config files it should use revision control. This is now recommended by Gentoo to use dispatch-conf instead of etc-config. dispatch-conf maintains all the files in RCS so it is easy to know
who changed them and revert to old changes. It is actually setup so a user can simply modify the config file and the next time the automated system needs to work with these files it can know if the system changed or the user directly.

I just looked at config_confd which is a program based on libconf. It is really nice. It provides a non validating, non structured view of configuration files. It basically provides a gui that enforces the way the confd config files are supposed to be used. This is a great default view for files that don't have a formal schema. I don't think it will work well for all files though.

Another interesting twist I realized is: many config files specify options of a program. If the program options were also documented in a formal way. Then schema of these config files would be greatly simplified. In these cases the maintaince then falls to the documentor that used to create the man page. In the config file schema there would just be a need to say which program and maybe a filter for the available options. The config editor would then lookup the schema for the program options and use that to generate the user interface controls.